大家好！歡迎來到這次的 30 天鐵人賽系列。

「今天中午吃什麼？」、「週末該約哪間餐廳？」這絕對是現代人每天都在經歷的大難題。

隨著社群媒體、Google 地圖與各類食記 App 的普及，我們身處在一個「美食資訊嚴重過載」的時代。然而，資訊變多並沒有讓我們更容易做決定，反而經常面臨嚴重的選擇障礙。

在這 30 天的挑戰中，我們將透過現代熱門的低代碼（Low-code）工具結合生成式 AI 與真實世界地圖資料，動手打造一個真正懂吃、懂你需求的「AI 美食探店與聚餐小助手」！

傳統找餐廳的四大核心痛點

當我們打開手機搜尋美食時，往往會遇到以下困擾：

• 篩選條件生硬零碎：想找「有插座、安靜、適合讀書且甜點好吃的咖啡廳」，在現成地圖 App 裡通常只能勾選簡單標籤，很難同時精準滿足多重複合需求。
• 網路評價真假難辨：五星好評可能是五星吹捧送小菜換來的，長篇食記可能是業配合作文，需要耗費大量時間逐則翻閱負評才能抓出真實評價。
• 選擇困難無從下手：好不容易挑出了三四家口袋名單，卻在群組裡問了半天「大家都好、都可以」，最後陷入決策僵局。
• 私房名單缺乏整理：滑 IG 或 Threads 收藏了一堆漂亮的咖啡廳或隱藏版甜點店，真正要出門時卻常常忘記存去哪裡，無法有效檢索。

解決方案：打造一個具備推論與行動能力的「AI 美食 Agent」

大語言模型（LLM）擅長理解口語化語意與統整評價，但單純問 ChatGPT「推薦我附近的咖啡廳」，模型因為不知道你的精確位置，也查不到店家此時此刻有沒有營業，往往會給出過時甚至胡說八道的幻覺答案。

因此，我們需要打造的是一個具備手腳的 AI Agent（智慧代理）：

• 感知與理解：聽懂你的口語化需求（例如：「我現在在輔大站附近，預算 200 內，想找有布丁或巴斯克蛋糕、不限時的店」）。
• 呼叫外部工具：即時呼叫 Google Places API 取得周邊店家的真實營業時間、評分與地址。
• 結合私房知識庫（RAG）：比對個人收錄的在地探店筆記與社群推薦清單。
• 結構化決策輸出：自動整理出推薦理由、必點招牌與避坑叮嚀，甚至產生聚餐投票轉盤。

核心技術選型與系統架構

為了兼顧實用性、低維護成本與快速迭代，我們選用了當前最熱門的資通訊與自動化工具：

• Dify（AI 應用開發平台）：系統的「大腦」。負責 Prompt 角色設定、RAG 私房美食知識庫檢索，以及決定何時呼叫地圖搜尋工具。
• n8n（工作流自動化引擎）：系統的「神經與四肢」。負責串接 Webhook、向 Google Places API 發送請求、清洗雜亂資料，並將結果送回 AI。
• Google Maps / Places API：真實世界資料庫。提供全球最即時的餐廳評分、座標、照片與營業狀態。
• Line Messaging API：終端使用者介面。不用額外下載 App，直接在 Line 聊天室中以美觀的 Flex Message 卡片圖文互動。
• Docker & ngrok：開發環境容器化，並建立安全穿透通道，方便本地測試外部 Webhook。

30 天實作節奏與章節規劃

這 30 天我們將由淺入深，一步步完成系統組裝：

階段一：環境建置與 API 開發基礎篇（Day 1 ~ Day 5）

• 本地 Docker 架設 Dify 與 n8n
• 使用 ngrok 打通外網通道
• 申請與實測 Google Places API（Postman 調試）

階段二：n8n 自動化流程中樞篇（Day 6 ~ Day 9）

• Webhook 接收與 JSON 欄位清洗
• HTTP Request 動態呼叫地圖 API
• 營業狀態篩選與評分排序邏輯實作

階段三：Dify AI 大腦與知識庫建置篇（Day 10 ~ Day 16）

• 美食探店 Prompt Engineering
• 私房咖啡廳/甜點店 RAG 知識庫搭建
• Dify 自訂工具（Custom Tool）整合 n8n

階段四：智慧探店情境與功能落地篇（Day 17 ~ Day 22）

• 口語化找店與選擇障礙決策演算法
• 串接 Notion API 實現自動化食記收藏
• 對接 Line Bot 並設計漂亮的視覺化推薦卡片

階段五：資安、維運與架構總結篇（Day 23 ~ Day 30）

• API Key 額度控管與安全限制
• 提示詞注入（Prompt Injection）防禦
• 容器雲端輕量部署與 30 天完賽覆盤

明天 【Day 2】，我們將正式進入動手實作環節，使用 Docker Compose 在本機一鍵啟動 Dify 與 n8n 的開發環境，明天見！